FIG. 1 shows an exemplary network structure of a Long Term Evolution (LTE) system as a related art mobile communication system. The LTE system is a system that has evolved from the existing UMTS system, and its standardization work is currently being performed by the 3GPP standards organization.
The LTE network can roughly be divided into an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) and a Core Network (CN). The E-UTRAN generally comprises a terminal (i.e., User Equipment (UE)), a base station (i.e., eNode B), an Access Gateway (aGW) that is located at an end of the network and connects with one or more external networks. The aGW may be divided into a portion for handling user traffic and a portion for processing control traffic. In this case, the access gateway part that processes the user traffic and the access gateway part that processes the control traffic may communicate with a new interface. One or more cells may exist in a single eNB. An interface may be used for transmitting user traffic or control traffic between eNBs. The CN may include the access gateway and a node or the like for user registration of the UE. An interface for discriminating the E-UTRAN and the CN may be used.
FIG. 2 shows an exemplary control plane architecture of a radio interface protocol between a terminal and an E-UTRAN according to the 3GPP radio access network standard. FIG. 3 shows an exemplary user plane architecture of a radio interface protocol between a terminal and an E-UTRAN according to the 3GPP radio access network standard.
Hereinafter, structures of radio interface protocols between a terminal and an E-UTRAN will be described with reference to FIGS. 2 and 3.
The radio interface protocol is horizontally comprised of a physical layer, a data link layer, and a network layer, and vertically comprised of a user plane for transmitting user data and a control plane for transferring control signaling. The protocol layer as shown in FIGS. 2 and 3 may be divided into L1 (Layer 1), L2 (Layer 2), and L3 (Layer 3) based upon the lower three layers of the Open System Interconnection (OSI) standards model that is widely known in the field of communication systems. These radio protocol layers exist as pairs between the terminal and the E-UTRAN and handle a data transmission over a radio interface.
Hereinafter, particular layers of the radio protocol control plane of FIG. 2 and of the radio protocol user plane of FIG. 3 will be described below.
The physical layer (Layer 1) uses a physical channel to provide an information transfer service to a higher layer. The physical layer is connected with a medium access control (MAC) layer located thereabove via a transport channel, and data is transferred between the physical layer and the MAC layer via the transport channel. The transport channel is divided into a dedicated transport channel and a common channel according to whether or not a channel is shared. Also, between respectively different physical layers, namely, between the respective physical layers of the transmitting side (transmitter) and the receiving side (receiver), data is transmitted via a physical channel.
The second layer includes various layers. First, a medium access control (MAC) layer performs mapping various logical channels to various transport channels and performs logical channel multiplexing by mapping several logical channels to a single transport channel. The MAC layer is connected to an upper layer called a radio link control (RLC) layer by a logical channel. The logical channel is divided into a control channel that transmits information of the control plane and a traffic channel that transmits information of the user plane according to a type of transmitted information.
An RLC (Radio Resource Control) layer of the second layer segments and/or concatenates data received from an upper layer to adjust the data size so as for a lower layer to suitably transmit the data to a radio interface. In addition, in order to guarantee various QoSs (Quality of services) required by each radio bearer RB, the RLC layer provides three operational modes: a TM (Transparent Mode); a UM (Unacknowledged Mode); and an AM (Acknowledged Mode). In particular, the RLC layer operating in the AM (referred to as an ‘AM RLC layer’, hereinafter) performs a retransmission function through an automatic repeat and request (ARQ) function for a reliable data transmission.
A packet data convergence protocol (PDCP) layer of the second layer performs a function called header compression that reduces the size of a header of an IP packet, which is relatively large and includes unnecessary control information, in order to effectively transmit the IP packet such as an IPv4 or IPv6 in a radio interface having a narrow bandwidth. The header compression increases transmission efficiency between radio interfaces by allowing the header part of the data to transmit only the essential information.
The RRC layer located at the lowermost portion of the third layer is defined only in the control plane, and controls a logical channel, a transport channel and a physical channel in relation to configuration, reconfiguration, and the release of radio bearers (RBs). In this case, the RBs refer to a logical path provided by the first and second layers of the radio protocol for data transmission between the UE and the UTRAN. In general, configuration (or setup) of the RB refers to the process of stipulating the characteristics of a radio protocol layer and a channel required for providing a particular data service, and setting the respective detailed parameters and operational methods.
FIG. 4 shows an exemplary structure of a PDCP entity. Hereinafter, description of the PDCP entity will be given in detail. It should be noted that blocks as shown in FIG. 4 are functional blocks, therefore there may have a difference when actually implementing such blocks.
The PDCP entity is upwardly connected to the RRC layer or a user application, and downwardly to the RLC layer. Detailed structure thereof is described as below.
One PDCP entity as shown in FIG. 4 is comprised of a transmitting side and a receiving side. The transmitting side at the left may configure an SDU received from an upper layer as a PDU or configure control information generated by the PDCP entity itself as a PDU, and transmit the same to a peer PDCP entity as a receiving side. The receiving side at the right, the peer PDCP entity, abstracts PDCP SDU or control information from the PDCP PDU received from the transmitting side.
As described above, the PDU generated by the transmitting side of the PDCP entity may have two types of a Data PDU and a Control PDU. First, the PDCP Data PDU is a data block formed by processing the SDU received from the upper layer by the PDCP entity, and the PDCP Control PDU is a data block generated by the PDCP entity itself to deliver control information to the peer entity.
The PDCP Data PDU is generated in RBs of the user plane (U-plane) and the control plane (C-plane), and some functions of the PDCP entity are selectively applied according to the type of a used plane. That is, the header compression function is applied only to U-plane data, and an integrity protection function among the security functions is applied only to C-plane data. In addition to the integrity protection function, a ciphering function for data security may also be included in the security functions. Here, the ciphering function is applied to both the U-plane data and the C-plane data.
The PDCP Control PDU is generated in a U-plane RB only, and may be roughly divided into two types: a ‘PDCP status report’ for notifying a PDCP entity receiving buffer status to the transmitting side; and a ‘Header Compression (HC) feedback packet’ for notifying a status of a receiving side header decompressor to a transmitting side header compressor.
FIG. 5 is a block diagram illustrating processing steps of each PDCP PDU in a PDCP entity.
In particular, FIG. 5 shows processing steps of the three types of PDCP PDUs (i.e., the PDCP Data PDU, the PDCP control PDU for PDCP status report, and the PDCP Control PDU for header compression feedback) in the PDCP entity through paths {circle around (1)} to {circle around (8)}. Descriptions of the processing paths of the PDCP entity for each type of PDUs will be given as below.
1. The process of handling the PDCP Data PDU in the PDCP entity is related to the paths {circle around (1)}, {circle around (8)}, {circle around (3)} and {circle around (7)}. Hereinafter, each path will be described.
Path {circle around (1)}: The transmitting side PDCP performs the header compression and security on a SDU received from an upper layer, and then generates a PDCP Data PDU by adding a PDCP Sequence Number (SN), a D/C field indicating whether it is Data PDU or Control PDU, etc. into a header, thereby transmitting the same to the receiving side PDCP entity (i.e., the peer PDCP entity). Here, the header compression may be performed by a header compressor.
Path {circle around (8)}: The receiving side PDCP entity removes the header from the PDCP Data PDU delivered from the lower layer, and decompresses the PDCP SDU by performing the security check and header decompression, thereby delivering the same to the upper layer. The PDCP SDU is delivered in sequence to the upper layer. If the PDCP SDU is received out of sequence, it is reordered in a receiving buffer and then delivered to the upper layer. Here, the header decompression may be performed by a header decompressor.
Path {circle around (3)}: The transmitting PDCP entity may piggyback a HC feedback packet on the PDCP Data PDU (e.g., the HC feedback packet is transmitted by being added or included in the PDCP Data PDU). Here, the HC feedback packet receives information from the header decompression of the receiving side PDCP entity which is co-located to the transmitting side PDCP entity, and generates a packet by piggybacking such information on the PDCP SDU when performing the header compression on the PDCP SDU received from the upper layer. Then, the security is performed on the PDCP SDU and the piggybacked HC feedback packet, and the PDCP SN, D/C field, etc. are added into the header so as to generate the PDCP Data PDU, and thusly to be transmitted to the receiving side PDCP entity from the transmitting side PDCP entity.
Path {circle around (7)}: Upon reception of the PDCP Data PDU, the receiving side PDCP entity removes the header first, and performs the security check and the header decompression so as to decompress the PDCP SDU. Here, if the piggybacked HC feedback packet is present, it is abstracted and delivered to the header compression of the co-located transmitting side PDCP entity. Upon receiving the HC feedback packet, the header compression of the transmitting side PDCP entity may determine whether the next packet should be delivered in a full header or a compressed header according to the feedback information.
2. The process of handling the PDCP control PDU for PDCP status report in the PDCP entity is related to the paths {circle around (2)} and {circle around (5)}. Hereinafter, each path will be described.
Path {circle around (2)}: The receiving side PDCP entity may check the receiving buffer to request a retransmission of PDCP SDU having not been received from the transmitting side PDCP entity. Here, the receiving buffer status is configured as a PDCP status report, and the configured PDCP status report is transmitted to the co-located transmitting side PDCP entity in the form of the Control PDU. Meanwhile, the header of the PDCP Control PDU may include a D/C field indicating whether the PDU is the Data PDU or the Control PDU, a Control PDU Type (CPT) field indicating whether the Control PDU includes the PDCP status report or the HC feedback packet, and the like.
Path {circle around (5)}: Upon receiving the PDCP Control PDU including the PDCP status report, the receiving side PDCP entity delivers the received PDCP status report to the co-located transmitting side PDCP entity. Based on the PDPC status report, the co-located transmitting side PDCP entity retransmits the PDCP SDU having not been received by the receiving side PDCP entity.
3. The process of handling the PDCP Control PDU for HC feedback in the PDCP entity is related to the paths {circle around (4)} and {circle around (6)}. Hereinafter, each path will be described.
Path {circle around (4)}: The transmitting side PDCP entity may transmit the PDCP Control PDU by independently including the HC feedback packet therein, without piggybacking the HC feedback packet on the PDCP Data PDU. Here, the HC feedback packet receives information from the header decompression of the receiving side PDCP entity which is co-located to the transmitting side PDCP entity. The HC feedback packet is configured as the PDCP Control PDU by adding the D/C field, the CPT field, etc. into the header, and then transmitted to the receiving side PDCP entity as a peer entity.
Path {circle around (6)}: Upon receiving the PDPC Control PDU including the HC feedback, the receiving side PDCP entity delivers the same to the header compression of the co-located transmitting side PDCP entity. Upon receiving the PDPC Control PDU, the header compression of the transmitting side PDCP entity may determine, according to the feedback information, whether the next packet should be delivered in a full header or a compressed header.